Add openssl_overrides to conduit context#390
Closed
lippirk wants to merge 1 commit into
Closed
Conversation
d071837 to
a0ce016
Compare
This patch really belongs in cohttp, but I don't think conduit
exposes all the right machinery.
This patch allows openssl cohttp-lwt-unix users to:
(a) connect to a particular hostname/IP, but specify something else to
verify against
(b) have direct control over the lifetime of their client's ssl context
I believe you should be able to achieve (a) using the following
resolver (but it results in 'not supported' errors):
```
let resolver =
let table = Hashtbl.create 16 in
let cn = "expected-cn" in
let Ok ip = Ipaddr.of_string cn in
Hashtbl.add table cn (`TLS (cn, `TCP (ip, port)));
Resolver_lwt_unix.static table
```
It's not possible to achieve (b) right now (at least in v2).
(b) is useful if your trusted bundle changes (calling
`load_verify_locations` with the same SSL context does not work as
one might expect). The alternative is to restart your application.
Intended usage with cohttp:
```
let ctx : Ssl.context = ... in
let openssl_overrides =
let open Conduit_lwt_unix_ssl.Overrides in
{
client =
Some Client.{ ctx = Some ctx; hostname = Some cn };
}
in
let* (ctx : Conduit_lwt_unix.ctx) = Conduit_lwt_unix.init ~openssl_overrides () in
let ctx : Cohttp_lwt_unix.Client.ctx = Cohttp_lwt_unix.Client.custom_ctx ~ctx () in
let* _resp, resp_body = Client.call ~ctx `POST ~body uri in
...
```
a0ce016 to
82b17d2
Compare
Author
|
I resolved some conflicts to do with the lazy changes |
Merged
|
How are the chances of getting this merged? We are also considering a refinement of this to support not verifying the hostname. This is a behavior that |
Merged
1 task
Contributor
|
This can now be closed now that we've settled on a different method to bypass hostname verification and pass the ssl context to the OpenSSL clients |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch really belongs in cohttp, but I don't think conduit
exposes all the right machinery.
This patch allows openssl cohttp-lwt-unix users to:
(a) connect to a particular hostname/IP, but specify something else to
verify against
(b) have direct control over the lifetime of their client's ssl context
I believe you should be able to achieve (a) using the following
resolver (but it results in 'not supported' errors):
It's not possible to achieve (b) right now (at least in v2).
(b) is useful if your trusted bundle changes (calling
load_verify_locationswith the same SSL context does not work asone might expect). The alternative is to restart your application.
Intended usage with cohttp: